Method and system for associating parameters of containers and contained objects

ABSTRACT

A system and method for establishing associative relationships between properties of a contained object and corresponding parameters of a container application is disclosed herein. In one embodiment the present system contemplates the establishment of both mutual and unilateral associative relationships, with a particular relationship being specified via a user interface created upon instantiation of the contained object. The associative relationships may be advantageously established without modification of the code comprising the contained object.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to co-pendingU.S. patent application Ser. No. 10/939,109, filed Sep. 10, 2004,entitled METHOD AND SYSTEM FOR ASSOCIATING PARAMETERS OF CONTAINERS ANDCONTAINED OBJECTS, which is a continuation of U.S. patent applicationSer. No. 09/241,938, filed Feb. 1, 1999, now U.S. Pat. No. 6,810,522,entitled METHOD AND SYSTEM FOR ASSOCIATING PARAMETERS OF CONTAINERS ANDCONTAINED OBJECTS, which claims priority to U.S. Provisional PatentApplication Ser. No. 60/103,362, filed Oct. 7, 1998, entitled METHOD ANDSYSTEM FOR ASSOCIATING PARAMETERS OF CONTAINERS AND CONTAINED OBJECTS.The content of each of these applications is hereby incorporated byreference herein in its entirety for all purposes.

FIELD OF THE INVENTION

This invention relates generally to data processing systems and, moreparticularly, to a method and system for creating associations betweenparameters of a container application program and correspondingparameter of a contained object.

BACKGROUND

The operation of a computer system is controlled by a computer programor group of programs called the operating system (“OS”). In earlyoperating systems, a computer user input text commands to the OS using acommand line interface. Later, more advanced operating systems weredeveloped which utilized a graphical user interface (“GUI”) incombination with an input device such as a mouse. In GUIs, the inputdevice controls a display cursor to allow for the selection of data andresources for application program operations. A user selects anoperation by highlighting an item or field and pressing a graphicalinput device button.

Many GUI programs are implemented in object-oriented programminglanguages, such as the C++ programming language. The display icons thatrepresent data or resources are typically representations of datastructures called objects, which encapsulate attributes and behaviors.Objects are specified by definitions, called classes, that specify theattributes and behaviors of the particular objects, which are termed“instantiations” of the class definitions. The reference Budd, T., “AnIntroduction to Object-Oriented Programming”, Addison-Wesley PublishingCo., Inc. 1991, provides an introduction to object-oriented concepts andterminology.

Object-oriented programming languages make it easier for systemprogrammers to implement the GUI concepts of icons and lists. Forexample, if the GUI icons are represented as object-oriented programmingobjects, the GUI program can be written so that the status of the iconis continuously updated. In this way, it is relatively simple for theGUI program to be written so that the icons can be selected with thegraphical user input device and moved about on the computer systemdisplay as desired.

With the advent of object-oriented GUIs also came object orienteddeveloping environments. Such development environments are computerprograms or groups of computer programs that allow a software developerto create object oriented programs. Object-oriented developmentenvironments typically have a palette of objects with which thedeveloper builds an application. Each object on this palette isdifferent and serves as a template for the developer. A palette object'sattribute settings are the default settings for that object. To use anobject on the palette, the developer copies the object and places thecopy on the application. The copied or “derived” object has the sameattribute settings as the original palette object.

Efforts have been made to establish a common method of communicationbetween objects instantiated within a given operating systemenvironment. For example, Microsoft Corporation has established acertain protocol, known as the Component Object Model, which governs theinteraction between software objects within the Microsoft Windowsoperating environment. COM provides a standard framework permittingobjects from different applications to share data and functions, andpermits a given application program (“container application”) to containmultiple objects of different types. Recently, a format for controlobjects known as “ActiveX” has been established to take advantage of theCOM protocol. An ActiveX object behaves as a “server” relative to itscontainer application, which in turn behaves as a “client”. The COMprotocol manages, among other things, the setup and initializationnecessary for container applications to send and receive messages anddata to and from server applications.

An ActiveX control is an object which typically includes data andfunctions, and which is capable of notifying its container applicationof the occurrence of an event. In the context of an ActiveX control,stored data members are known as “properties”, functions are referred toas “methods”, and event occurrences are denoted as “events”. Propertiescan be read from, and written to, an ActiveX control via associatedmethods. The interface of an ActiveX control is a set of methodsdefining certain input, output and behavior rules. Accordingly, acontainer application can invoke the methods of an ActiveX control toeffect the defined behavior and access the object data.

In addition to representing data stored by an ActiveX control,properties are used in formatting the display of an ActiveX control.Events are utilized to notify a container application of the occurrenceof an event, as well as to pass parameters relevant to the particularevent. For example, an ActiveX control is capable of informing itscontainer application of the occurrence of a selection event (e.g., whenthe user interface of the control has been “clicked on”).

ActiveX objects are typically implemented: (i) as in-process servers, or(ii) as out-of-process servers. In the former case the ActiveX controlis implemented as a Dynamic Link Library (“DLL”), and in the latter caseas an “executable”. ActiveX DLL's are loaded into the process space ofthe container application. As a consequence, data does not need to betransported between the container application and the ActiveX control.In contrast, ActiveX executables are loaded into a separate processspace from the container application. Since there is no shared memorybetween such applications, data is transported between ActiveX objectsand the container application. This is advantageous in the sense that anActiveX executable does not interfere with the processing of data in theclient application.

Although a number of programming environments exist for facilitatingdevelopment of Active X controls, as object-oriented constructs eachsuch ActiveX control operates independently of the containerapplication. That is, Active X controls are conventionally installed incontainer applications so as not to be affected by changes in parametersof the container application, and vice versa. Similarly, the occurrenceof ActiveX events does not automatically cause the execution of scriptsor the like in the container application. Although such relationshipsbetween the properties and events of an ActiveX control and a containerapplication could conceivably be established on an ad hoc basis, therehas not heretofore been a convenient mechanism for linking suchproperties and events with associated parameters of containerapplications.

SUMMARY

Briefly, the present invention provides a system and method forestablishing associative relationships between properties of a containedobject and corresponding parameters of a container application. Thepresent system contemplates the establishment of both mutual andunilateral associative relationships, with a particular relationshipbeing specified via a user interface created upon instantiation of thecontained object. It is a feature of the present invention that suchassociative relationships may be established without modification of thecode comprising the contained object.

In one aspect the present invention facilitates implementation ofselected functionality of a container application prescribed by an eventscript. In an initial step an association is created between an eventarising within a contained object instantiated in a computingenvironment and a script associated with the container application. In apreferred implementation this association is recorded in an event sinkof a control site serving the container application. An event indicationis generated in response to occurrence of a particular event within thecontained object. In response, the event script is invoked and asequence of script commands corresponding to the selected functionalityare carried out.

In another aspect the present invention provides a system and method forcreating an association between a tag source of a container applicationand a property of a contained object. Specifically, an associativerelationship is defined between said tag source and the property, suchassociative relationship being determinative of the extent to whichchanges in the tag source and property will induce corresponding changesin the other. This associative relationship is recorded within aproperty sink of a control site for the container application, and maybe specified by a user upon instantiation of the contained object.Depending upon the nature of the tag source, various unilateral andmutual associative relationships may be established. For example, incertain instances a unilateral associative relationship may be specifiedsuch that changes in the tag source are reflected as correspondingchanges in the property, while changes in the property are not permittedto affect the tag source. In other cases the converse unilateralassociative relationship, or a mutual associative relationship, may alsobe specified.

Additional aspect of the present invention are further described belowin conjunction with the appended Drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings:

FIG. 1 is a block diagram of a computer system in which the presentinvention may be implemented.

FIG. 2 is a diagram of a dialog box for a bound object which has beeninstantiated in a container application in accordance with the presentinvention.

FIG. 3 provides a view of the dialog box of FIG. 2 in which the eventspage has been selected.

FIG. 4 provides a graphical representation of an instance of aninstalled object and the resulting control site established within awindow of a container application as a consequence of suchinstantiation.

FIG. 5 shows a block diagram of the structure of a property sinkincluded within the control site of FIG. 4.

FIG. 6 shows a block diagram of the structure of an event sink includedwithin the control site of FIG. 4

FIG. 7 shows a tag object of a type identified by a particular field ofthe property sink of FIG. 5.

FIG. 8 provides a block diagram of the structure of a property object ofthe type identified by a particular field of the property sink of FIG.5.

FIGS. 9 and 10 are respective flowchart representations of the manner inwhich changes in properties of a container application potentiallyinduce corresponding changes in tags of an instantiated object, and viceversa.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION Overview

The present invention provides a generalized method for creatingassociations between parameters of programming objects, such as ActiveXcontrols, and associated parameters of a container application. That is,properties and events of ActiveX controls are respectively bound to datavariables (i.e., “tags”) and scripts of the container application. Thecontainer application could comprise, for example, industrial automationand control software having tags representative of the state of varioussensors or industrial processes. Scripts of the container applicationinclude a sequence of script commands for invoking functionality of thecontainer application, thereby allowing a user to specify how theapplication operates.

FIG. 1 is a block diagram of a computer system 100 in which, the presentinvention may be implemented. The computer system 100 includes a userstation 102 that communicates with a system storage unit over network106. The system storage unit 104 comprises a direct access storagedevice, such as magnetic disk storage, in which data files are stored.The user station 102 includes a central processing unit (“CPU”) 108, adisplay 110, and a main memory 112. The CPU operates in response to usercommands, which it receives via a keyboard 114 or graphical user inputdevice 116. The user station 102 can communicate with one or more otheruser stations or a network server unit over the network 106.

The main memory 112 contains a variety of data structures andinformation, including an operating system, application programs,program objects, and user data. The main memory is represented as asingle entity, but those skilled in the art will appreciate that themain memory can comprise a combination of random access memory (“RAM”),hard disk drives, optical disk drives, and other storage devicescontaining logically segmented storage locations. The main memoryincludes a computer program containing a sequence of programinstructions whose execution implements the present invention.

The operating system contained in the memory 112 supports anobject-oriented programming environment for the execution ofobject-oriented programs, such as those written in, for example, the C++programming language. Accordingly, the memory contains program objectsthat are data structures of an object-oriented programming language.Application programs are invoked, or launched, by a user through thekeyboard 114 or graphical input device 116. The application programs canbe written in a variety of languages, including C++.

The display 110 comprises a display device such as a video terminal thatdisplays computer output and indicates system operations. Displayobjects can be pictured on the display and the user can designate dataoperations on the display by using the input device 116 or equivalentgraphical user input device.

In an exemplary implementation the computer system 100 may also sendcommands to, and receive data from, one or more industrial sensor orprocess control devices 120. The state of each such device 120 isreflected by the value of an associated tag, each of which may be aparameter of the container application. In the exemplary implementationthe container application comprises an industrial automation softwareprogram, such as the InTouch program module developed by WonderwareCorporation of Irvine, Calif. The Wonderware Intouch module includes atool kit for building screens and interfaces, and a graphical userinterface for monitoring and controlling the devices 120. For example,in the context of electrical distribution the software toolkit of theWonderware Intouch module enables rapid development of three dimensionalrepresentations of electrical distribution switchgear. The switchgearelevational representations have logical connections to the switchgeardevices. An elevation can be modified to any dimensions with anessentially infinite number of combinations and arrangements of metersand protection devices to quickly and accurately represent a customer'sswitchgear. In addition, a tabular representation of metering andsetup/set point information is generated automatically with theappropriate database server links established. The Wonderware Intouchmodule is disposed to provide similar representations and accompanyingdatabase links in other areas of industrial automation and control.

Display and Editing of Associative Relationships

FIG. 2 is a diagram of a dialog box 150 for a bound object which hasbeen instantiated in a container application as described hereinafter.In the exemplary implementation of FIG. 2, the bound object comprises anActiveX control identified as TextControl. When instantiated in acontainer application using conventional techniques, the dialog box 150could be expected to include the “Control Name”, “General”, “Colors” and“Fonts” pages. In accordance with the invention, a “properties” page isincluded to provide a mechanism for viewing and altering relationshipsbetween properties of the bound object (i.e., TextControl) andcorresponding tags of the container application. In addition, an“events” page serves to display the relationship between various eventsof the bound object and associated scripts of the container application.

Referring to FIG. 2, the properties page of TextControl reveals that theproperty BackColor is bound to the tag backgroundcolor of the containerapplication. The arrow graphic 152 indicates that a bidirectionalrelationship has been established between the property BackColor and theassociated tag backgroundcolor. That is, changes in the value of the tagbackgroundcolor will be reflected in the value of the propertyBackColor, and vice versa.

FIG. 2 also indicates that the property BottomTextLine is bound to thetag textline3 of the container application. The arrow graphic 154indicates that changes to the tag textline3 will result in correspondingchanges being made to the property BottomTextLine. The solid verticalline at the right edge of the arrow graphic 154 indicates that a userwill not be permitted to define the relationship between BottomTextLineand textline3 such that changes to the former induce correspondingchanges to the latter. This situation may arise when, for example, thetag textline3 is “read only”, or when there exists some other reason whyit is impermissible to bind the tag textline3 to the propertyBottomTextLine.

It is also seen that that the property ForeColor is bound to the tagtextcolor of the container application. The arrow graphic 156 indicatesthat changes to the tag textcolor will result in corresponding changesbeing made to the property ForeColor. The absence of a right-pointingarrow in arrow graphic 156 indicates that changes to ForeColor will notaffect the value of textcolor. Since a solid vertical line does notappear at the right edge of the arrow graphic 156, a user will bepermitted to allow changes in the property ForeColor to causecorresponding changes in the tag textcolor.

FIG. 2 further shows the property TextJustification to be bound to thetag tag1. However, the absence of any arrow graphic proximate thedisplayed name tag1 indicates that changes to the propertyTextJustification will not induce changes in the tag tag1, nor viceversa.

FIG. 3 provides a view of the dialog box 150 in which the events pagehas been selected. This view reveals that the event Click is bound tothe script ClickScript of the container application. In the exemplaryimplementation of FIG. 3 no further graphic representation is providedof the binding between the event Click and the property ClickScript.

Referring again to FIG. 2, the associations between the parameters ofthe bound objects and corresponding tags of the container applicationmay be modified by using the graphical input device 116 to change thestate of the applicable arrow graphic. For example, in a particularimplementation each arrow graphic will cycle between various permittedassociative states (e.g., unidirectional, bidirectional) in response torepeated selection by the device 116.

Establishment of Associative Relationships Between CorrespondingParameters

In a preferred embodiment, the binding between a container applicationand a bound object is implemented using the capability of the underlyingwindow system. The present invention is described assuming, forexemplary purposes and without limitation, that the underlying windowsystem is similar to the Microsoft Windows 3.1 operating system(“Windows”). Except as otherwise noted hereinafter, conventionaltechniques are utilized to install objects (e.g., an ActiveX control)within the Windows environment for subsequent binding to a containerapplication in accordance with the invention. Once an object has beeninstalled, the process of binding an object to a container applicationin accordance with the invention is initiated by instantiating theinstalled object in the container application.

In an exemplary embodiment the container application comprises anobject-oriented industrial automation program such as, for example, theInTouch program developed by Wonderware Corporation of Irvine, Calif. Inthis exemplary embodiment the container application creates windowswhich themselves function as containers for ActiveX control objects.After a control object has been placed in such a window and itsparameter associations have been selected via a dialog box (FIG. 2), thewindow may be saved and closed in response to commands provided to thecontainer application. A compiling operation is preferably invoked whenthe container window and contained control object are saved, therebycreating a “compiled window”. The container window and contained controlobject may then be generated from the compiled window during subsequentexecution of the container application.

Upon such placement of an installed object in a window of the containerapplication, a dialog box such as that shown in FIG. 2 is presented viadisplay 110. The desired associations between properties of theinstalled object and tags of the container object may then be selectedvia pointing device 116 so as to create a bound object. Once one or moreinstalled objects have been so bound to the container application, thewindow of the container may be compiled with the bound objects so as tocreate a “compiled window”. During execution of the containerapplication the compiled window is read and interpreted, which resultsin the creation of the bound object within the run-time environment. Ina preferred implementation the compiled window is stored as a file ofpredefined format, in which each object (e.g., shapes, wizard utilities,ActiveX controls) present within the window of the container applicationis represented as a block of data. Utilization of a particularpredefined format for the compiled window file is not necessary forimplementation of the present invention, and differing file formats forthe compiled window may offer advantages in particular applications.

FIG. 4 provides a graphical representation of an instance 160 of aninstalled object and the resulting control site 162 established within awindow 166 of a container application as a consequence of suchinstantiation. Those skilled in the art will appreciate that a standardcontrol site having certain well defined properties is generated uponplacement of an object such as an ActiveX control within a window of aWindows compatible container application. In accordance with theinvention, the control site 162 differs from such a standard controlsite in that sets of one or more property sinks 168 and event sinks 170are provided to facilitate the parameter associations depicted in FIGS.2 and 3. The control site 162 defines a standard interface 172 forcommunicating with the instantiated object 160 through a correspondingstandard interface 174 thereof.

Referring to FIG. 5, there is shown a block diagram of the structure ofa property sink 168 included within the control site 162. The propertysink 168 defines a tagname field 178 for identifying the name of the tagto be associated with the property object specified by the pointerwithin the field 180. An association field 182 specifies the type ofassociation (e.g., unidirectional) to be established between the tagobject and property object identified by the pointers within the fields184 and 180, respectively. In the exemplary case of FIG. 5, theassociation field 182 would specify a unidirectional relationshipbetween the tag object textcolor and the property objectTextJustification. The association field 182 registers any change in therelationship between a tag object and corresponding property objecteffected using the pointing device 116 in the manner described abovewith reference to FIG. 2.

FIG. 6 shows a block diagram of the structure of an event sink 185included within the control site 162. The event sink 185 defines aDISPID field 186 containing an identifier corresponding to a givenevent. In addition, a CString field 187 is provided for storing the nameof a script for the container application associated with the event. Thename in the CString field is provided to the container application inresponse to occurrence of the given event, which executes thecorresponding script.

Referring to FIG. 7, there is shown a tag object 190 of the typeidentified by field 184 of the property sink of FIG. 5. The tag object190 includes a tagname field 192, PTACC handle field 194, and statusflag field 196. The contents of the tagname field 192 will be identicalto the contents of the tagname field 178 included within the propertysink 168. In a preferred embodiment the PTACC handle field 194 providesa unique identifier for a particular tag. This identifier is returned bya dynamically linked library (“DLL”) named “PTACC” to requesting thirdparty applications.

FIG. 8 provides a block diagram of the structure of a property object200 of the type identified by field 180 of the property sink of FIG. 5.As is indicated by FIG. 8, the property object 200 includes a DISPIDfield 202 for identifying a particular parameter of the bound object(e.g., ActiveX control). In an exemplary implementation the industrystandard dispatch interface (“IDispatch”) of the bound object furnishesan index stored in the DISPID field in response to a call by thecontainer application for a method of the bound object. The containerapplication then calls an “Invoke” method of the object's dispatchinterface, which causes the object to retrieve the method associatedwith the index in the DISPID field 202. The desired method is thencalled by the bound object.

The property object 200 further defines a “CString” field 204 forstoring the name of the tag corresponding to the container propertyassociated with such tag. Also included within the property object 200is an “ASSOCTYPE” field 206 which records the type of associationbetween such container property and tag. In addition, a “COcxTag” field208 is provided for storing a pointer to an object wrapper surroundingmethods used by the container application to interface with tags. Theproperty object 200 also defines a “COcxProperty” field 212 for holdinga pointer to an object wrapper surrounding methods for changingproperties of the bound object.

Mapping Changes Between Corresponding Properties and Tags

When a compiled window (described above) is loaded during execution ofthe container application, the property sinks 168 and event sinks 170associated with the compiled window are regenerated and used to recordany change in the operative association between properties of boundobjects and corresponding tags of the container application. FIGS. 9 and10 are respective flowchart representations of the manner in whichchanges in such properties potentially induce corresponding changes insuch tags, and vice versa.

Referring to FIG. 9, in step 220 a property of a bound object is causedto change in state or value (i.e., a “property change”) and theassociated control site (FIG. 4) of the bound object is notified (step222). It is then determined whether the notification received at thecontrol site is with regard to a property change (step 224). If not, nofurther processing relating to a potential change in the value of anassociated container tag is performed (step 226). If the notificationcorresponds to a property change, it is attempted to identify theproperty sink (FIG. 5) corresponding to the property being changed (step228). If a corresponding property sink is not found (step 230), then nofurther processing is performed (step 232). In the case where acorresponding property sink is identified, an OnEvent member function iscalled (step 234). The OnEvent member function serves to convert theproperty change into a corresponding change in state or value of theassociated tag (i.e., a “tag change”).

In step 236, an operation is performed to validate the proposed tagchange arising from the property change. In a preferred implementationthis validation process entails determining whether the proposed tagchange is within a predefined range of valid tag values. If the proposedchange is not validated (step 238), no further processing is performed(step 240). In the case where the property change is validated, thecontainer application makes the corresponding validated change in theassociated tag (step 242).

Referring now to FIG. 10, in step 250 a tag change is experienced by atag monitored by the container application and a notification message isgenerated in response. In step 254 it is then determined whether thenotification message corresponds to an industry standard “DBCHANGE”message (i.e., a type of message which has been registered in theWindows environment to facilitate interpretation by a receivingapplication). If not, no further efforts are made to make a propertychange corresponding to the tag change (step 256). If the window messagecorresponds to a DBCHANGE message, it is attempted to identify theproperty sink (FIG. 5) associated with the tag experiencing a change(step 258). If an associated property sink is not found (step 260), thenno further processing is performed (step 262). In the case where acorresponding property sink is identified, an OnTagChange memberfunction is called (step 264). The OnTagChange member function serves toconvert the tag change into a corresponding property change.

In step 266, an operation is performed to validate the parametersreturned by the OnTagChange member function. In a preferredimplementation this validation process entails determining whether theproposed property change falls within a predefined range. If theproposed change is not validated, no further processing is performed(step 267). In the case where the property change is validated (step268), a pointer to the appropriate property object is retrieved from theassociated property sink (step 270). If the retrieved pointer is invalid(step 272), then no further processing is performed (step 274). If avalid pointer has been retrieved, then a corresponding change is made inthe associated property via an interface of the application program(step 276).

In a preferred implementation of the procedure set forth in FIG. 10,several object classes described in CODE SECTION I are invoked.Specifically, CTagServer and CocxTag are classes disposed to “wrap”various methods for interfacing with the tags monitored by the containerapplication. Each “wrapper” instance of this class provides an interfacebetween the container application and any proprietary methods forinterfacing with such tags. The class CpropSink corresponds to aspecific implementation of a property sink. The class CocxProperty isdesigned to wrap properties of control objects and to store pointers(i.e., IDispatch) associated locations of such properties. The SetValuemember function uses the IDispatch pointer to change the value of acontrol object property associated with a tag experiencing acorresponding change. In CODE SECTION I, the “//” expression is used toidentifies comments to the code.

Code Section I CTagServer:

LRESULT CTagServer::WindowProc(UINT message, WPARAM wParam, LPARAMlParam) {    if (message == m_DbChgMsg)    {      // interpret thelParam as a handle of a tag        HPT hPt = (HPT) lParam;        // Getthe tag associated with this message.        COcxTag* pTag = (COcxTag*)GetExtraLong(hPt, 0);        if (!pTag)        return false;        //Get the sink associated with this tag.        ITagChange* pSink =(ITagChange*) GetExtraLong(hPt, sizeof(LONG));        // if there is asink call it else call tags virtual method.        if (pSink)       pSink->OnTagChange(pTag);        else       pTag->OnTagChange(NULL);    return TRUE;    }    returnCWnd::WindowProc(message, wParam, lParam); }

OnTagChange:

void CPropSink::OnTagChange(COcxTag*) {    // make sure there is aproperty object associated with this tag    // if not then initializeone    if (!m_pProp)    InitProperty( );    // verify that there is aproperty, tag and that the association between    // the two indicatesthat the tag changes the property (this relationship    // is defined bythe graphic on the property page when the association    // is defined)   if (m_bIgnoreChange || !m_pProp || !m_pTag ||    ((m_assocType !=TAG_CHANGES_PROP) &&    (m_assocType != BOTH)))    return;    // someflags here solve some timing problems intended to solve    // circularevents. ie. Tag change property which changes tag which    // changesproperty...    m_bIgnoreChange = true;   m_pProp->SetValue(m_pTag->GetValue( ));    m_bIgnoreChange = false;

Execution of Container Scripts in Response to Events

As is indicated by FIG. 3, the dialog box of a bound object representsany association existing between event occurrences in the object andscripts defined by the container application. In the exemplaryembodiment of FIG. 3, a user may alter such associations by performingediting operations upon the dialog box displayed by the events page.

In CODE SECTION II below, exemplary code is provided for effecting theassociation of event occurrences to the execution of container scriptscontemplated by the present invention. Specifically, CODE SECTION IIincludes the definition of a class “CScriptSink” disposed to facilitateimplementation of the event sinks described with reference to FIG. 6. Inparticular, CScriptSink causes event notification messages generated bythe bound object to be registered and sent to the container application.CODE SECTION II further includes definition of a class defined as“COcxItem”, which is responsible for creating control sites in responseto instantiation of bound objects as described above with reference toFIG. 4. Also defined is the member function “OnCmdMsg”, which isoperative to: (i) determine the type of an event notification which hasoccurred, (ii) locate the associated container script per therelationship defined in the applicable events page (e.g., FIG. 3), and(iii) cause execution of the associated script. Calls to the functionOnCmdMsg may be made in accordance with the standard COM protocol.

Code Section II COcxItem:

BOOL COcxItem::OnCmdMsg(UINT nID, int nCode, void* pExtra,       AFX_CMDHANDLERINFO* pHandlerInfo) {  AFX_EVENT* pEvent =(AFX_EVENT*) pExtra;  if (nCode == CN_EVENT && !m_bDesignMode)  {  COcxSink* pSink = NULL;   switch (pEvent->m_eventKind)   {    caseAFX_EVENT::event:    {     // get the event sinks          CString sText;     pSink =m_EventSinks.GetItem(pEvent->m_dispid);     if(!pSink)      returnfalse;     // create an event object           COcxEvent event(pEvent,this);           // Get the script name for the current event          sText = pSink->GetText( );     // cause the script to execute          pSink->OnEvent(&event, sText);     return true;    }        //         // other cases here         //   }  }  returnCWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo);

CScriptSink:

void CScriptSink::OnEvent(COcxEvent* pEvent, CString szScriptName) { CString szComposed;  CString szEventName;  UINT dwParamCount;  UINTdwIndex;  CString szParamName;  _variant_t vtParamValue; CEventTableUtil event;  // essentially build up a structure that holdsthe types    // and values for the script to execute properly   szEventName = pEvent->GetEventName( );  dwParamCount =pEvent->GetParamCount( );  szComposed = szEventName;  for (dwIndex = 0;dwIndex < dwParamCount; dwIndex++)  {   szParamName =pEvent->GetParamName(dwIndex);   vtParamValue =pEvent->GetParamValue(dwIndex);   szComposed += szParamName;  event.AddNamedVariant((LPCSTR)szComposed, vtParamValue);   szComposed= szEventName;  }    // register the message    wWizardCallMsg =   RegisterWindowMessage(“InTouchWizardCallMsg”);    // send theregistered message over to the main application OesExecuteScript(m_sText, pEvent->GetOcxInstanceName( ));    // clearout the table of parameter information  event.ResetContent( );

Although the above application has been described primarily in terms ofparticular implementations of techniques for creating associationsbetween contained objects and various parameters of containerapplications, one skilled in the art will be able to develop alternativeimplementations based upon the teachings herein. Thus the application ismeant only to be limited by the scope of the appended claims.

1. A method for creating a persistent association between a factoryautomation parameter of a container application operative within acomputing environment and a property of a contained object instantiatedwithin said computing environment, wherein said property relates toattributes of said contained object and said container application isconfigured to provide a visual interface representative of states ofsaid factory automation parameter, said method comprising the steps of:defining a persistent associative relationship between said factoryautomation parameter and said property, said persistent associativerelationship being determinative of the extent to which changes in saidfactory automation parameter and said property will induce correspondingchanges in the other; and recording said persistent associativerelationship within a property sink of a control site of said containerapplication, said control site being created upon instantiation of saidcontained object within said computing environment wherein saidcontained object facilitates provision of a visual indication of ones ofsaid states of said factory automation parameter.
 2. A system forcreating a persistent association, between a factory automationparameter of a container application operative within a computingenvironment and a property of a contained object instantiated withinsaid computing environment, wherein said property relates to attributesof said contained object and said container application is configured toprovide a visual interface representative of states of said factoryautomation parameter, said system comprising: at least one processor;memory operably coupled to the processor, wherein the processor executesinstructions stored in the memory to: define a persistent associativerelationship between said factory automation parameter and saidproperty, said persistent associative relationship being determinativeof the extent to which changes in said factory automation parameter andsaid property will induce corresponding changes in the other whereinsaid contained object facilitates provision of a visual indication ofones of said states of said factory automation parameter; and recordsaid persistent associative relationship in a property sink includedwithin a control site associated with said container application.
 3. Amethod for creating a persistent association between a tag source of acontainer application operative within a computing environment and aproperty of a contained object instantiated within said computingenvironment, wherein said property relates to attributes of saidcontained object and said container application is configured to providea visual interface representative of states of monitored parameters ofan industrial process, said method comprising the steps of: defining apersistent associative relationship between said tag source and saidproperty, said persistent associative relationship being determinativeof the extent to which changes in said tag source and said property willinduce corresponding changes in the other; and recording said persistentassociative relationship within a property sink of a control site ofsaid container application, said control site being created uponinstantiation of said contained object within said computing environmentwherein said contained object facilitates provision of a visualindication of ones of said states of at least one of said monitoredparameters defined by said tag source.
 4. A system for creating apersistent association between a tag source of a container applicationoperative within a computing environment and a property of a containedobject instantiated within said computing environment, wherein saidproperty relates to attributes of said contained object and saidcontainer application is configured to provide a visual interfacerepresentative of states of monitored parameters of an industrialprocess, said system comprising: at least one processor; memory operablycoupled to the processor, wherein the processor executes instructionsstored in the memory to: define a persistent associative relationshipbetween said tag source and said property, said persistent associativerelationship being determinative of the extent to which changes in saidtag source and said property will induce corresponding changes in theother wherein said contained object facilitates provision of a visualindication of ones of said states of at least one of said monitoredparameters defined by said tag source; and record said persistentassociative relationship in a property sink included within a controlsite associated with said container application.
 5. A system forcreating a persistent association between a parameter of a containerapplication operative within a computing environment and a property of acontained object instantiated within said computing environment, saidcontainer application being configured to provide a visual interfacerepresentative of states of monitored parameters of an industrialprocess, said system comprising: at least one processor; and a memoryoperably coupled to the processor, wherein the processor executesinstructions stored in the memory to record a persistent associativerelationship in a property sink included within a control siteassociated with said container application, said persistent associativerelationship being established between said parameter and said propertyduring instantiation of said contained object within said computingenvironment wherein said contained object facilitates provision of avisual indication of ones of said states of at least one of saidmonitored parameters, said persistent associative relationship beingdeterminative of the extent to which changes in said parameter and saidproperty will induce corresponding changes in the other.